At present, the 3rd Generation Partnership Project (generally known as ‘3GPP’) has introduced the basis for an IP Multimedia Subsystem (generally known as ‘IMS’) and IMS services, as stated in the technical specification 3GPP TS 23.228 V6.9.0. In accordance with 3GPP, Public Service Identities are different from Public User Identities in the respect that the former identify services, which may be hosted and operated by application servers (generally known as ‘AS’ in at least said 3GPP technical specification), whereas the latter identify users whose subscription data are hosted in subscriber databases under network operator premises, and who are served by different serving network nodes such as a Serving Call Session Control Function (known as ‘S-CSCF’ under 3GPP). A definition of the terms ‘Service’ and ‘user’, as used throughout this specification can be found in 3GPP TS 21.905: “Vocabulary for 3GPP Specifications”.
Generally speaking, Public Service Identities are used to identify services running on specific application servers. In particular, Public Service Identities are used to identify groups of services such as a chat-type service, for instance, that may use a Public Service Identity (hereinafter referred to as ‘PSI’) to which the users may establish a session in order to enable the sending and reception of messages from other session participants. Public Service Identities are presently assumed to take the form of SIP URL or SIP URI as defined by the Internet Engineering Task Forces (IETF) in RFC 3261 and RFC 2396, as well as in the so-called ‘tel:’-URI format as defined in RFC 3966. An exemplary Public Service Identity (PSI) identifying a chat-type service may be sip:chatlist_X@example.com.
Public User Identities can adopt two different forms of representation and scope. A first one is a so-called ‘Distinct PSI’, such as sip:my_service@example.com, and determines an individual Public Service Identity representing a unique service and which can be individually invoked. A second scope and form of representation is a so-called ‘Wildcard PSI’, such as sip:chatlist_*@example.com may be, wherein a range of Public User Identities is defined with a same domain part in the SIP URI and with a wildcard indication in the user part of the SIP URI. An interested reader may find definitions for ‘Distinct PSI’ and ‘Wildcard PSI’ through the technical specification 3GPP TS 23.003.
In this respect, an individual Public Service Identity might have been defined independently as a ‘Distinct PSI’, or might have been defined within a ‘Wildcard PSI’ range, which implicitly includes a plurality of Public Service Identities within the range.
In operation, the IMS provides the means for routing IMS messages related to particular IMS services by using corresponding Public Service Identities.
Therefore, Public Service Identities are stored in a Home Subscriber Server (generally known as ‘HSS’ under 3GPP specifications) holding subscription data for subscribers of a home network operator. A service may be invoked by a user accessing IMS through a Proxy Call Session Control Function (known as ‘P-CSCF’ under 3GPP) by using a given Public Service Identity. This invocation is received at a routing entity of the home network, preferably an Interrogating Call Session Control Function (known as ‘I-CSCF’ under 3GPP), which interrogates the HSS about the given Public Service Identity. The HSS checks whether the given Public Service Identity is defined in the HSS in order to find an S-CSCF already assigned for handling the given Public Service Identity, or an application server where the corresponding service runs if the network is configured for such direct invocation, or server capabilities required for selecting an S-CSCF if such serving entity is not assigned yet for the given Public Service Identity.
If no S-CSCF was already assigned at the HSS for handling the given Public Service Identity, the server capabilities received at the I-CSCF are used to select an appropriate S-CSCF for handling the service. The service invocation with the given Public Service Identity is forwarded to the selected S-CSCF, which informs the HSS in order to be assigned therein as currently serving the given Public Service Identity. As for the previous interrogation, the HSS checks whether the given Public Service Identity is defined in the HSS in order to mark the assigned S-CSCF, and in order to fetch an applicable service profile for the given Public Service Identity to be returned towards the S-CSCF.
This service profile includes an identifier of the Application Server where the corresponding service is executed so that, once the applicable service profile for the given Public Service Identity is obtained at the S-CSCF, the S-CSCF may forward the invocation of the service towards the Application Server indicated in the service profile. The Application Server (generally abbreviated as “AS”) then checks whether the given Public Service Identity is defined and fetches the logic to be executed for the given Public Service Identity.
With the currently existing mechanism, the routing of an invocation of service identified by a Public Service Identity includes at least two checking procedures in the HSS in order to match the given Public Service Identity with those Public Service Identities defined in the HSS, and one checking procedure in the AS in order to fetch the service logic associated with the given Public Service Identity. These checking procedures may become more complex than expected as trying to match the given Public Service Identity against all the individually defined Public Service Identities and against those Public Service Identities implicitly defined within a so-called ‘Wildcard PSI’ range.
These three checking procedures are increased to, at least, four checking procedures in networks where more than one HSS exists since, prior to interrogate an HSS about a Public Service Identity, the routing entity should firstly interrogate a central entity in the network about the Public Service Identity in order to obtain an identifier of the HSS holding such Public Service Identity. In such scenario with more than one HSS, Public Service Identities might have been defined in any HSS of the network, individually as a ‘Distinct PSI’ or within a ‘Wildcard PSI’ range, and a checking procedure is required at least four times in order to identify relevant data to apply for a given Public Service Identity.
Moreover, each service profile received for a given Public Service Identity at the S-CSCF is stored therein so that further invocations with respective Public Service Identities may not require download of a service profile if a service profile were already stored for each Public Service Identity.